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inventors Luis Valente, Venkatachary Srinivasan, Andreas Atkins and Wei Ling 
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Background of the Invention 

Field of the Invention 

This invention relates to computer security. 
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l 2. Related Art 



2 



3 In a data delivery system, data receivers need to know whether they can 

4 trust information they receive from senders. This need is increasing due to the growth of 



5 data exchanges and business transactions taking place on the Internet over non-secure 



6 communication links. 



7 



8 The growing Public Key Infrastructure ("PKI") provides a way for 

□ 9 receivers of data to know whether they can trust information they receive from senders. 

Ul ! io In the PKI, trusted third parties issue digital certificates ("public key certificates") that 

m 1 1 attest to the authenticity of the binding of a public key to its owner. These trusted third 

12 parties are known as certification authorities "CAs", or sometimes are called "public 

2 13 CAs" if their services are available to the public. These digital certificates are created 

U 14 and used using known encryption and decryption security techniques. Verisign, Inc. is an 

h0 15 example of a public CA. Senders obtain a certificate from a CA, and include the 

16 certificate with the data they wish to send to the receiver The certificate includes enough 



n information for the receiver to verify that the sender's self-identification is accurate 
1 8 (verification of identity), and that the data was not compromised between the sender and 



19 the receiver (validation of contents). 



20 



2i The PKI has the general drawback that digital certificates accepted by the 



22 receiver are limited to those from certification authorities that the receiver already trusts. 



3 
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1 Thus the general problem of providing trust information to the receiver is inherent in the 

2 PKI. The trust information required by the receiver can include the identities of trusted 

3 senders, for what purpose the senders are trusted, and sufficient information to 

4 authenticate messages from the trusted senders. 

5 

6 For instance, Secure Socket Layer ("SSL) is a widely adopted protocol that 

7 is used within the PKI for authentication and encryption. To authenticate a message, the 

8 client must have enough trust information regarding the digital certificate sent by the SSL 
O 9 server ("server certificate ")--at a minimum the client must have an authentic copy of the 
(fj io certificate of the CA who issued the SSL server certificate. However, computers, 

if 1 1 particularly in the consumer market, have limited resources, including limited nonvolatile 

; P 12 storage, to store such information. 

m 13 

U 14 A computer administrator must decide which CAs to trust. In the case of 

; A 15 personal computers used in homes or small offices, the user may be unsophisticated, 

16 lacking in knowledge, or unwilling to make and implement his trust decisions. A 

n common solution is providing a factory-defined set of trust relationships. This makes the 

1 8 security measures transparently available to the user. However it is impractical for 

1 9 inexpensive personal computing devices due to the high cost of nonvolatile memory. In 

20 addition this solution provides a static set of trust relationships, and does not provide for 

21 updates. 



4 



NCI-061 

1 The Incorporated Disclosures provide a method for a computing device to 

2 acquire trust information after it is manufactured. These applications disclose the general 

3 approach of using Security Information Objects ("SIOs"), with a single Trusted Security 

4 Information Provider (or at least a single level of TSIPs defining the trust relationship for 

5 all parties. One drawback of the method disclosed is only the TSIP can issue an SIO. 

6 Furthermore, the TSIP must administer all parties's trust information, when the TSIP may 

7 only be interested in detailed definition of the trust relationship between the TSIP and its 

8 closest business partners. Yet, the TSIP may wish to retain some general control over 
O 9 what other partners can do. 

,3: jr.. 

|| 1 1 In addition, complex interrelated business relationships exist and are 

I s 12 evolving on the Internet, and it is desirable to design a system that will also provide 

S'13 accountability and enforcement of complex business relationships and rules. An example 

j«* 14 business hierarchy is shown in FIG. 1, and is discussed in detail in the Detailed 

* 1 5 Description below. Referring to FIG. 1 , using the method disclosed in the Incorporated 

16 Disclosures, OEM1 and OEM2 would be indistinguishable to ISP1 and ISP2. However, 

17 it may be desired to distinguish between OEM1 and OEM2, for instance so that if ISP 1 is 

18 a client of OEM1, it can be prevented from subscribing to services of OEM2. Or, so 

1 9 OEM2 cannot steal customers of OEM 1 . 

20 

2 1 Accordingly, it would be advantageous for a security system to provide a 

22 way for each business party to dynamically provide trust information to its clients based 
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1 on its own business and security requirements, while centralized control is maintained 

2 where desired. The system would be transparent to the end-user, and would be easy to 



3 implement. 



4 



5 The invention provides a Hierarchical Open Security Information 

6 Delegation and Acquisition System which allows secure and dynamic distribution of 

7 security information to multiple clients over non-secure channels. It also allows parties 

8 to modify the security information, within boundaries that are set by higher-level parties. 
O 9 Such modification can include adding third-party CAs to the list of entities trusted to 

io issue SSL certificates. It provides a technique for each business party to define its own 

III 1 1 trust relationships with other entities including public CAs, within the parameters that are 

4* 12 hierarchically set. 

Si 13 

U 14 Summary of the Invention 

J3 15 The invention provides a method and system for secure data transfer and 

16 dynamic definition of trustworthiness of various entities by multiple parties in a hierarchy 

17 tree or graph structure. The invention uses digital certificates. Each party in the 

18 business hierarchy can control and define various trust information including 

19 trustworthiness and delegation authority for the entities it deals with. The ability of a 

20 party to redefine or add trust information is controlled by the parties with which it has a 

21 relationship that are above it in the hierarchy. Trust vectors and delegation vectors are 

22 used to store this information. Each party can add trusted third parties to a security 
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object without compromising the integrity of security objects already issued. A sequence 
of security objects including digital certificates can be modified without compromising 
the original digital certificates in those security objects 

Brief Description of the Drawings 

FIG. 1 shows an example business hierarchy. 

FIG. 2 shows the general format of an X509 version 3 certificate. 

FIG. 3 shows a schematic of root certificate chaining. 

FIG. 4 shows a sample Root Security Information Object for an OEM. 

FIG. 5 shows sample values given to bits in the trust-delegation vector. 

FIG. 6 shows a schematic of how an HSIO chain of RSIOs is linked. 

FIG. 7 shows a process flow diagram for a client to validate a Hierarchical 

Security Information Object. 

FIG. 8 shows a process flow diagram whereby an SSL server certificate can 

be authenticated. 

Detailed Description of the Preferred Embodiment 
In the following description, a preferred embodiment of the invention is 
described with regard to preferred process steps and data structures. Those skilled in the 
art would recognize after perusal of this application that embodiments of the invention 
can be implemented using one or more general purpose processors or special purpose 
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1 processors or other circuits adapted to particular process steps and data structures 

2 described herein, and that implementation of the process steps and data structures 

3 described herein would not require undue experimentation or further invention. 

4 

5 Alternative embodiments may use other and further forms of authentication 

6 and certification, using other forms of cryptography either in addition to or instead of 

7 public key cryptography, and are within the scope and spirit of the invention. 

8 

□ 9 Inventions disclosed herein can be used in conjunction with inventions 

yi J io disclosed in the Incorporated Disclosures, referenced previously. 

\ ^ 
jfS.B. 

T *T? 

12 Overview of the Invention 

-I -t 

^ 14 The invention provides a secure and dynamic way of distributing trust 

fKKSS; 

JI is information from a centralized authority to parties in a hierarchy that have a relationship 

16 with it. Among other things, it provides client with enough information to identify 

n trusted SSL servers and authenticate messages from them. It allows each party to define 

18 its own trust relationship with the other business parties in the hierarchy and with other 

19 entities, including public CAs, within boundaries that are set hierarchically. 

20 

21 The invention provides a way for the hierarchical structure of business 

22 relationships to be incorporated into a security system. The party that is directly above 

8 
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1 another party in the hierarchy has control over the security information of the lower 

2 party— including what kind of third-party entities can be added by the lower party. 

3 

4 A root certificate of the top-level entity in the hierarchy, the Software 

5 Provider ("SP") in the preferred embodiment, is preferably stored in non-volatile memory 

6 of a computing device at the time of manufacture. Because subsequent SP root 

7 certificates are chained together as described in the Incorporated Disclosures , the 

8 computing device can verify any later SP root certificate by chaining back to the one 

O 9 stored in its non-volatile memory. (Or, it can verify by chaining back to a more recent SP 

£!J 10 root certificate it has stored locally subsequent to time of manufacture.) 

\ is 

m ii 

^ 12 Each of the other parties provides its own root certificate to the party 

Pfl 13 directly above it in the hierarchy. The higher party includes a fingerprint of the lower 

l*f 14 party's root certificate in a digital object, called the Root Security Information Object 

15 (RSIO). This allows a path to be verified through the hierarchy, by matching a lower 

16 party to its root certificate fingerprint. 

17 

18 Each party can define detailed trust information, including additional 

19 trusted third-party public CAs. Each party generates its own RSIO, which it digitally 

20 signs and passes to the next higher party in the tree. RSIOs are the basic source of trust 

21 information. 

22 
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For any party in the hierarchy, a path can be traced back to the top level 
party. Each party in the path has an RSIO. When the RSIOs are chained together, that 
object is called a Hierarchical Security Information Object (HSIO). The RSIOs of the 
parties (chained into an HSIO) are able to authenticate by tracing an unbroken path of 
authentication all the way back to the top of the tree, i.e. the Software Provider in the 
preferred embodiment. Because the SP's root certificate is locally available to all other 
parties, it can verify the SP's RSIO and each subsequent RSIO can also be verified, given 
the structure of the RSIOs, as described below. 

Definitions 

A "digital certificate" is a non-forgeable ? tamper-proof electronic document 
that binds an entity's identity to its public key, as is known in the art of public key 
cryptography. Public key cryptography is discussed in the Incorporated Disclosures. 
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A "root certificate" is a self-signed and self-authenticating digital 

certificate. 



5 An entity's "fingerprint" or "signature" is unique data that another entity can 

6 recognize as genuine but cannot duplicate. It can function as a person's fingerprint or 

7 signature functions in everyday life. In the preferred embodiment, an entity's fingerprint 

8 is a SHA- 1 hash of its X.509 version 3 certificate. 

a 9 

i*$ 10 A "client" is any computing device that participates in the system, including 

Whs 1 

fill 1 1 a classical end-user of a conventional network. Examples of a client are a conventional 

'** 12 personal computer or workstation, personal digital assistant, a set-top box, cellular 

13 telephone, or digital pager. In discussions of the preferred embodiment the term "client" 

M 14 refers to a set-top box used by a customer of an ISP which could be, for instance, a cable 

15 tv service. 

16 

17 A "party" is one of the entities that is authorized to issue RSIOs. 

18 



19 Business Scenario in the Preferred Embodiment 



20 
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1 For clarity, the invention is described as applied to a business model in the 

2 consumer market, as described below, with the hierarchy having three levels. A sample 

3 business hierarchy is shown in FIG. 1. 

4 

5 In the preferred embodiment, the party at the top of the hierarchy is the 

6 Software Provider (SP). It provides software that runs on servers and clients of a web- 

7 based TV system. 

8 

□ 9 The SP has a business contract with one or more Original Equipment 

H io Manufacturers ("OEMs"), for the OEM to manufacture and distribute client and server 

111 l i devices that use SP's software. The OEM is the owner of the hardware (servers and 

"P 12 clients that run SP's software) used by the lower levels. The OEM is a large national 

| 13 cable TV company that broadcasts shows. The OEM is the middle level of the hierarchy. 

M 14 

13 ! 5 The OEM contracts with one or more Internet Service Providers ("ISPs"). 

16 The ISP provides service to individual customers. The ISP also provides its customers 

n with OEM client computers running SP software. The ISP is a small local cable 

18 company. The hierarchy can assume many shapes. For example, an ISP may contract 

19 with several OEMs, or an OEM may contract with several ISPs. 

20 

21 The invention can be practiced with many other business models. Thetop- 

22 level entity need not be a software provider and need not be affiliated with web-based 

12 
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1 TV. It can be any entity requiring computer security, including a financial institution, an 

2 insurance company, a retail store, a government agency, etc. Likewise, the lower-level 

3 entities, if any, can be any entities having a business relationship with the other entities. 

4 Currently in the cable television business, it is common for an OEM to also function as 

5 the ISP. The business model can have fewer or more than three levels. 



7 Root Certificates 
8 

q 9 Each party in the hierarchy provides a root certificate. The root certificate 

14 o is preferably in X509 version 3 format. A schematic depiction of this format is shown in 

iji l FIG. 2. Preferably a period of time for which the certificate is valid is stored in the root 

12 certificate in the field that is labeled Period of Validity in FIG. 2. (A party's root 



certificate is provided to the party immediately above it in the hierarchy. This higher 



ui4 party incorporates the root certificate into the as described below.) 

, ;■{«< 

y*Ji5 

16 There are three types of root certificates in the preferred embodiment: SP 

17 root certificate, OEM root certificate, and ISP root certificate. 

18 

19 Chaining of SP Root Certificate 

20 

21 Being the top authority, the SP root certificates are chained together as 

22 described in the Incorporated Disclosures. Using this locally stored root certificate, 

13 
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subsequent chained SP root certificates can be verified and validated, as described in the 
Incorporated Disclosures. Briefly, root certificate chaining is accomplished by placing, 
in the current certificate, a digest-obtained by means of a one-way secure hash function- 
-of the public key of the next key pair, i.e. the key pair which will replace the current key 
pair when the current certificate expires. FIG. 3 illustrates root certificate chaining. 

Revocation of the root certificate is accomplished. 

At the time of manufacture, the most recent and valid root certificate for the 
SP is stored in nonvolatile memory of the computing device. When an updated SP root 
certificate is received, the computing device stores this most recent root certificate. 
(Thus, a later SP root certificate need only be verified to the most recent root certificate 
that the computing device has previously stored, which saves time.) However, if the 
client system reverts to its initial operating state (for instance because of a system 
malfunction resulting in the loss of all data in writable storage), the client will always be 
capable of verifying a later root certificate using the root certificate that is stored in the 
computing device's nonvolatile memory at the time of manufacture. 

OEM and ISP Root Certificates: self-signed and self-authenticating 

The root certificates of lower level entities (OEM and ISP root certificates 
in the preferred embodiment) are just like any public CA certificates: they are self-signed 

14 
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1 and self-authenticating as known in the art of cryptography. They are not chained 

2 together. To renew or revoke such a root certificate, the certificate is with new key pairs. 



5 Root Security Information Object and Hierarchical Security Information Object 



l Each party (SP ? OEM, ISP) generates its own root security information 

8 object (RSIO). A sample RSIO for an OEM is shown in FIG. 4. The RSIO is digitally 

9 signed by the entity (preferably, by the entity's current root key pair), and preferably 
o contains a timestamp . 



iiili 

;S5BJj 

Hi 2 The OEM's RSIO and the ISP's RSIO each contains its current active root 



13 certificate. The SP ! s RSIO preferably contains the SP's entire root certificate chain. That 

gfti4 is, referring to FIG. 4 (which shows a sample OEM RSIO), for an SP RSIO instead of 

is merely having the root certificate for the SP, the entire chain of root certificates for the 

*16 SP is included. 

17 

18 A party's RSIO preferably contains an entry for each entity directly below 

19 the party in the hierarchy and can also include a list of the third party CAs that the party 

20 trusts. Each trusted entity (preferably either an OEM, ISP, or third party CA) has an 

21 entry in the RSIO. Each entity is identified by its fingerprint (to save space). 

22 
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1 The trust information for the each trusted entity is given in the RSIO, and is 

2 preferably implemented by a vector of bits. The delegation information for each trusted 

3 entity is given, and is preferably implemented by a vector of bits. 

4 

5 Trust Vector and Delegation Vector 

6 

7 Each entity has associated with it a trust vector. Each bit in the trust vector 

8 designates a role the entity may play. Preferably, some bits in the trust vector indicate 
H 9 things the entity may do. A sample trust and delegation vector is shown in FIG. 5. For 
Ulio example, bit 0 may indicate that the entity is a CA trusted to issue certificates for SSL 
S l clients, and bit 1 may indicate that the entity is a CA trusted to issue certificates for SSL 
J12 servers. There may be different grades of SSL servers governed by different bits. 

f; 14 The trust bits can also indicate what role a Public CA can play. For 

■fli 5 example, some Public CAs may only be trusted to issue certificates for low-security 

16 applications such as personal email, whereas other Public CAs may be trusted to issue 

17 certificates for high-security application such as securities trading or electronic funds 

18 transfer. 

19 

20 Other bits in the trust vector identify the entity as belonging to a certain 

21 class, which is trusted to do certain acts. For instance, bit 2 may indicate that the entity is 

22 an OEM (and thus trusted to issue OEM RSIOs) and bit 3 may indicate that the entity is 

16 
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1 an ISP (and thus trusted to issue ISP RSIOs. Other bits may indicate the entity is one of 

2 SP's special business partners such an SP system software publisher, which is trusted to 

3 do certain acts, 

4 

5 Preferably, each trusted Entity listed in the RSIO has associated with it a 

6 delegation vector. Preferably, each bit in the delegation vector designates whether the 

7 corresponding trust vector bit may be turned on by the entity next lowest in the RSIO 

8 hierarchy. For instance, the delegation vector in the RSIO for a specific OEM indicates 

9 what bits ISPs of that OEM may turn on. This has the effect that an ISP may reduce the 
Uio trust roles the OEM has assigned an entity (by turning off a trust bit) but may not enlarge 

l the trust roles the OEM has assigned to an entity in the RSIO. 

J5 12 

£1 3 In addition to enabling the OEM to retain control of the changes that an 

f*i4 ISP may make, the delegation vector enables the SP to define what authority the OEM or 

05 any lower level party has. Thus, the SP can control to some extent what authority all 

16 other parties have by being able to prohibit lower entities authority to take certain actions 

n by turning off the delegation vector bit for that action. 

18 

1 9 Chaining of RSIOs 

20 

21 The RSIO for an entity contains the fingerprints of its children in the 

22 hierarchy. The fingerprint is preferably a hash of the root certificate. That is, the OEM's 

17 
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l RSIO contains a hash of the ISP's root certificate, and the SP f s RSIO contains a hash of 



2 the OEM's root certificate. 



3 



4 A chain of RSIO's from the SFs RSIO to OEM's RSIO to ISP's RSIO forms 



5 a Hierarchical Security Information Object. Preferably the chain is formed using the 



6 fingerprint of the root certificate of the next entity in the chain as the link, as shown 



7 schematically in FIG. 6. For instance, the SP RSIO can be linked to OEMl's RSIO by 



8 matching OEMl's fingerprint in the SP's RSIO to the OEM1 identification in OEM1 's 



O 9 RSIO. 



hi 10 

nil li HSIO Validation 



«3* n 



J 13 In the preferred embodiment, the client obtains updated trust information 



Mi: 14 via an HSIO. Before the client relies on the trust information in the HSIO, it must check 
1 5 that the HSIO is genuine and has not been tampered with. An HSIO is a chain of RSIO's 



1 6 from the client back to the SP. In the preferred embodiment, for a client of ISP 1, that is 



n an ISP of OEM1, the RSIO chain will consist of SP's RSIO— >OEMl's RSIO— >ISPPs 



18 RSIO. 



19 



20 The client can validate the HSIO by the following procedure set out in FIG. 



21 7. First check the validity date of the ISP RSIO against the current date. If it is a valid 



22 date, then verify the ISP's RSIO by verifying its signature using the ISP root certificate 
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1 which is in the ISP RSIO. Check that the ISP fingerprint (hash of its root certificate) is 

2 contained in the OEM's RSIO. Check the validity date of the OEM's RSIO, and verify 

3 the OEM signature in the OEM RSIO. Check that the OEM fingerprint (hash of its root 

4 certificate) is contained in the SP's RSIO. Validate the SP's RSIO by the procedure 

5 described in the above and in the Incorporated Disclosures 



6 



7 If the HSIO passes the checks set out in the previous paragraph, it is a valid 



8 and genuine HSIO. 



Q9 

U|o Update of HSIO 

;:i i 

i ¥ 

JS12 Preferably, the ISP generates new updated HSIOs, because it is the lowest 

'Pi3 level in the hierarchy, interacting directly with clients. (However, updating of HSIOs can 

[!j4 be done by another party.) To generate a new HSIO for a given chain, the ISP needs the 

ii5 current RSIOs of the SP, OEM, and its own RSIO. 



16 



n Preferably, the client periodically sends the latest timestamp of the three 

18 RSIOs in the HSIO (RSIO chain) to the ISP so that the ISP can determine whether a new 



19 HSIO should be sent. 



20 
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Events that trigger generation of a new HSIO are the issuance of a new root 
certificate by any link in the client-ISP-OEM-SP chain, and when the trust information in 
any of the RSIOs has changed. 

Example: Verification of a non-partner SSL server 

An example use of the invention is set forth here. The SSL protocol is 
widely used. It may often be desirable for a client to be able to do a transaction with a 
computer using SSL that is not one of the SP's business partners. For example, a client 
(cable TV customer) that wants to purchase products over a web-based TV application 
may need to exchange information with a financial institution SSL server. 

The client will receive a server certificate, either signed by a CA or else 
self-signed, from the third-party server. Suppose server certificate is signed by Verisign 
as a public CA. The client must determine whether this CA is trusted to issue a server 
certificate. 

In the preferred embodiment, the ISP is delegated authority to designate 
trusted SSL servers and to designate CAs trusted to sign SSL server certificates (In 
actual application any specific ISP may or may not have such authority depending on 
how higher level entities have delegated authority. To check whether an ISP has 
authority to designate CAs trusted to sign SSL certificates, the trust-delegation vector of 
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1 the OEM RSIO entry for this ISP would be checked.) In the preferred embodiment, the 

2 ISP having authority to designate CAs trusted to do so, the client checks the ISP RSIO to 

3 see if Verisign is included as a CA trusted to sign SSL server certificates. (Instead of a 

4 CA signing the server certificate, the server certificate may be self-signed, e.g. by 

5 Citibank. In such a case, the client checks the ISP RSIO to see whether Citibank is a 

6 trusted SSL server.) 

7 

8 If the CA signing the server certificate (Verisign in our example) is not 

9 authorized to do so in the ISP RSIO, then the client checks the OEM RSIO to see if 

Uao Verisign is included as a CA trusted to sign SSL server certificates. (Or, if instead of CA 

^ 1 such as Verisign signing, the server certificate is self signed, e.g. by Citibank, the client 

J12 checks the OEM RSIO to see that Citibank is a trusted SSL server.) 

h a 4 If no authorization is found in the ISP RSIO or the OEM RSIO, then the SP 

Jl5 RSIO is similarly checked. If this check fails, then the client cannot do a transaction with 

16 this SSL server. 

17 

18 If authorization is found in any of the RSIOs in the HSIO, then the standard 

19 SSL handshake protocol proceeds. 

20 

21 Example: Step-Up Encryption 

22 
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Using strong encryption internationally is strictly regulated by the U.S. 
government. However, a trust bit can be designated to control whether a party is not 
trusted to use strong encryption. Preferably, this trust bit would be turned off in the SP 
RSIO for computing devices where strong encryption is allowed. The respective 
delegation bit would also be turned off, so that lower level entities could not enable 
strong encryption. 

Alternative Embodiments 

Although preferred embodiments are disclosed herein, many variations are 
possible which remain within the concept, scope, and spirit of the invention, and these 
variations would become clear to those skilled in the art after perusal of this application. 
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l Claims 

2 

3 LA method, including steps of 

4 sending a first certificate from a first entity, said first certificate including 

5 security information regarding at least a second entity, said first certificate including 

6 information authenticating a second certificate from said second entity; and 

7 sending said second certificate from said second entity; 

8 whereby a recipient of said first certificate and said second certificate can 
^9 authenticate from information therein a first set of security information to associate with 
LJo said first entity and a second set of security information to associate with said second 
yi entity. 

|42- 

03 2. A method as in claim 1, wherein at least one of the following 

ft 4 includes a root certificate: said first certificate, said second certificate. 

16 3. A method as in claim 1, wherein 

17 said first certificate includes both an expiration date and information 

18 authenticating a third certificate; and 

19 said third certificate includes an expiration date other than said expiration 

20 date for said first certificate. 

21 
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1 4. A method as in claim 1, wherein said first certificate includes 

2 information authenticating a certificate from said first entity other than said first 

3 certificate. 



5 5. A method as in claim 1, wherein said first certificate includes 

6 information authenticating a future intended version of said first certificate. 



7 
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6. A method as in claim 1, wherein said second certificate includes 



8 

□9 information authenticating a third certificate. 

j|J i 7. A method as in claim 1, wherein 

said second certificate including security information regarding at least a 



third entity, said second certificate including information authenticating a third certificate 



from said third entity; 

O15 and including steps of sending said third certificate from said third entity 

16 

17 8. A method as in claim 1 , wherein said security information includes a 

18 set of authorizations for said second entity. 



9. An article of manufacture, said article including a computer data 



20 

21 signal embodied in readable medium, said readable medium including at least one of the 

22 following: a carrier wave, a memory, or a storage device; said data signal including 

24 
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1 a first certificate indicating a first entity as its source and including (a) 

2 security information regarding at least a second entity, and (b) information authenticating 

3 a second certificate from said second entity. 

4 

5 10. An article as in claim 9 ? including a second certificate indicating said 

6 second entity as its source; whereby a recipient of said first certificate and said second 

7 certificate can authenticate from information therein a first set of security information to 

8 associate with said first entity and a second set of security information to associate with 
p9 said second entity. 

3° 

.SB. 

Bji 11. An article as in claim 9, wherein at least one of the following 

"« 

=142 includes a root certificate: said first certificate, said second certificate. 

Ml 4 12. An article as in claim 9 5 wherein 

'sip? ■ 

] £ks said first certificate includes both an expiration date and information 

16 authenticating a third certificate; and 

n said third certificate includes an expiration date other than said expiration 

18 date for said first certificate. 

19 

20 13. An article as in claim 9, wherein said first certificate includes 

21 information authenticating a certificate from said first entity other than said first 

22 certificate. 
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14. An article as in claim 9, wherein said first certificate includes 
information authenticating a future intended version of said first certificate. 

15. An article as in claim 9, wherein said second certificate includes 
information authenticating a third certificate. 



16. An article as in claim 9, wherein 

said second certificate including security information regarding at least a 
third entity, said second certificate including information authenticating a third certificate 

from said third entity; 

and including steps of sending said third certificate from said third entity 

17. An article as in claim 9, wherein said security information includes a 
set of authorizations for said second entity. 
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Abstract of the Disclosure 
The invention provides a method and system for secure data transfer and 
dynamic definition of trustworthiness of various entities by multiple parties in a hierarchy 
tree or graph structure. The invention uses digital certificates. Each party in the business 
hierarchy can control and define various trust information including trustworthiness and 
delegation authority for the entities it deals with. The ability of a party to redefine or add 
trust information is controlled by the parties with which it has a relationship that are 
above it in the hierarchy. Trust vectors and delegation vectors are used to store this 
information. Each party can add trusted third parties to a security object without 
compromising the integrity of security objects already issued. A sequence of security 
objects including digital certificates can be modified without compromising the original 
digital certificates in those security objects. 
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FIG. 4 



SAMPLE OEM RSIO 





OEM Root Certificate 


(note: For an SP RSIO the entire chain of SP Root Certificates would be included. For an ISP RSIO the 


ISP Root Certificate would be included.) 




(Trusted Entity's Identity) 


(Trust Information) 


(Delegation Information) 


Entity 1 Fingerprint 


Entity 1 trust information 


Entity 1 delegation information 


Entity 2 Fingerprint 


Entity 2 trust information 


Entity 2 delegation information 


• 


•• • 




Entity m Fingerprint 


Entity m trust information 


Entity m delegation information 


CA 1 Fingerprint 


C A 1 trust information 


CA 1 delegation information 


CA 2 Fingerprint 


CA 2 trust information 


CA 2 delegation information 








CA n 


CA n trust information 


CA n delgation information 


Timestamp 


Signature 



FIG. 5 

SAMPLE TRUST-DELEGATION VECTOR 
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FIG. 7A 

Validation of an HSIO by ISP client 
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FIG. 8 

Authentication of an SSL server certificate 
from non-partner SSL server 
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